Method and apparatus for generating test bench for verification of processor decoder

ABSTRACT

A method and apparatus for generating a test bench for verifying a processor decoder are provided. The method including receiving an architecture description comprising processor decoder information, parsing the received architecture description into information for verifying the processor decoder, and generating the test bench to verify the processor decoder based on the parsed information.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.14/259,481, filed Apr. 23, 2014, which claims the benefit under 35 USC §119(a) of Korean Patent Application No. 10-2013-0120195, filed on Oct.8, 2013, in the Korean Intellectual Property Office, the entiredisclosures of which are incorporated herein by reference for allpurposes.

BACKGROUND 1. Field

The following description relates to methods and apparatuses forgenerating a test bench, and to methods and apparatuses for generating atest bench for verification of a processor decoder.

2. Description of the Related Art

As a plurality of processors are developed and verified, a plurality oftest benches that correspond to a plurality of processors are used. Asthe number of processors that are developed increases, the number oftest benches used for verifying the developed processors increases,which takes a long time.

SUMMARY

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subjectmatter.

In one general aspect, there is provided a method of generating a testbench to verify a processor decoder, the method including receiving anarchitecture description comprising processor decoder information,parsing the received architecture description into information forverifying the processor decoder, and generating the test bench to verifythe processor decoder based on the parsed information.

The parsing of the received architecture description may includeacquiring operation code (op-code) information, source information, anddestination information from the received architecture description.

The op-code information may include an operation code specification, thesource information comprises a source length, and the destinationinformation comprises a destination length.

The architecture description may include at least one of encoding schemeinformation, encoding bitmap information, or op-code information.

The encoding scheme information may include group code information.

The processor decoder may be one of a very long instruction word (VLIW)processor decoder or a processor decoder having a coarse grainedreconfigurable architecture (CGRA) structure.

The test bench may include a test vector.

The test bench may include a reference model of the processor decoder.

The method may include comparing results of inputting the test vectorinto the reference model and a design under test (DUT) processordecoder.

In another general aspect, there is provided an apparatus for generatinga test bench to verify a processor decoder, the apparatus including areceiver configured to receive an architecture description comprisingprocessor decoder information, a parser configured toparse the receivedarchitecture description into information for verifying the processordecoder, and a generator configured togenerate the test bench to verifythe processor decoder based on the parsed information.

The parser may be further configured to acquire operation code (op-code)information, source information, and destination information from thereceived architecture description.

The op-code information may include an operation code specification, thesource information comprises a source length, and the destinationinformation comprises a destination length.

The architecture description may include at least one of encoding schemeinformation, encoding bitmap information, or op-code information.

The encoding scheme information may include group code information.

The processor decoder may be one of a VLIW processor decoder or aprocessor decoder having a CGRA structure.

The test bench may include a test vector.

The test bench may include a reference model of the processor decoder.

The apparatus may include a comparator configured to compare results ofinputting the test vector into the reference model and a design undertest (DUT) processor decoder.

Other features and aspects will be apparent from the following detaileddescription, the drawings, and the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram illustrating an example of an apparatus forgenerating a test bench for verifying a processor decoder.

FIG. 2 is a diagram illustrating an example of an apparatus forgenerating a test bench for verifying a processor decoder.

FIG. 3 is a diagram illustrating an example of a test bench forverifying a processor decoder.

FIG. 4 is a diagram illustrating an example of information of anarchitecture description.

FIG. 5 is a diagram illustrating an example of a reference model of aprocessor decoder.

FIG. 6 is a diagram illustrating an example of a method of generating atest bench for verifying a processor decoder.

FIG. 7 is a diagram illustrating an example of a method of generating atest bench for verifying a processor decoder.

Throughout the drawings and the detailed description, unless otherwisedescribed, the same drawing reference numerals will be understood torefer to the same elements, features, and structures. The drawings maynot be to scale, and the relative size, proportions, and depiction ofelements in the drawings may be exaggerated for clarity, illustration,and convenience.

DETAILED DESCRIPTION

The following detailed description is provided to assist the reader ingaining a comprehensive understanding of the methods, apparatuses,and/or systems described herein. However, various changes,modifications, and equivalents of the systems, apparatuses and/ormethods described herein will be apparent to one of ordinary skill inthe art. The progression of processing steps and/or operations describedis an example; however, the sequence of and/or operations is not limitedto that set forth herein and may be changed as is known in the art, withthe exception of steps and/or operations necessarily occurring in acertain order. Also, descriptions of functions and constructions thatare well known to one of ordinary skill in the art may be omitted forincreased clarity and conciseness.

The features described herein may be embodied in different forms, andare not to be construed as being limited to the examples describedherein. Rather, the examples described herein have been provided so thatthis disclosure will be thorough and complete, and will convey the fullscope of the disclosure to one of ordinary skill in the art.

The term “part” refers to a software element or a hardware element suchas a field-programmable gate array (FPGA) or application-specificintegrated circuit (ASIC) and performs roles but is not limited tosoftware or hardware. The term “part” may be in a storage medium thatmay be addressed or may be constituted to reproduce one or moreprocessors. The term “part” includes elements, such as, for example,software elements, object-oriented software elements, glass elements,task elements, processes, functions, attributes, procedures,subroutines, segments of a program code, drivers, firmware, micro-codes,circuits, data, database, data structures, tables, arrays, andparameters. Functions provided in elements and “parts” may be combinedwith the smaller number of elements and “parts” or may be divided intoadditional elements and “parts.”

“Coarse Grained Reconfigurable Architecture” or “CGRA” may be a networkthat may be constituted together with several computing units andregister files and may be connected to the several computing units andregister files. Also, “Coarse Grained Reconfigurable Architecture” or“CGRA” is a combination of parallel processing hardware functionalityand flexibility of software.

“Very Long Instruction Word” or “VLIW” is a method of processing severalinstructions, i.e., one of operation processing technologies forsimultaneously executing several instructions.

In a scalar structure, a central processing unit (CPU) processes eachinstruction per clock cycle. An improvement of the scalar structure, asuper scalar method may process two or more instructions simultaneouslyor in less than one clock cycle. The super scalar method divides apipeline to use idle state hardware. As described above, a paralleloperation structure simultaneously performs instructions, which do notoverlap with each other, in parallel. Parts that wait for operations ina processor and that are in idle states are reduced to improve workefficiency and operation speed.

The VLIW refers to a method of performing a parallel operation by usinginstruction level parallelism (ILP) and including several simultaneouslyexecutable instructions, such as, for example, op-codes and operands, ina long instruction form to execute several operations whenever each ofthe instructions is withdrawn and executed. A instruction code is longbut is regarded as one instruction. Therefore, the instruction code iswithdrawn and decoded by one circuit, and only an execution cycle ofeach operation is simultaneously processed by several units (functionunits including an arithmetic logic unit (ALU)).

“Architecture description language” used herein is a language used todescribe a software architecture that describes a structure and anoperation of a software system that is a set of a software component, aconnection point, and an interactive operation. A unit that models andparses the software architecture is provided to enhance a quality andaccuracy of the software.

“Parsing” refers to a work that is involved in distinguishing elements,such as, for example, an operator, an operand, a keyword, which appearin a program. Parsing may be performed according to contents defined insyntax of a program and detecting structures of these elements,understanding a structure and job contents of the program input from alanguage interpreter such as a complier, an interpreter, or the like andtranslating the structure and the job contents into a machine language.“Parsing” may also refer to a job that is involved in distinguishing aninstruction, a factor, or a parameter that is input by a user in aninstruction processing apparatus to distinguish information input by theuser.

“Instruction” refers to a command for executing an operation in aprocessor. A general processor expresses an instruction as 32 bits.However, the instruction is not limited to 32 bits and other number ofbits, such as, for example, 64 bits, are considered to be well withinthe scope of the present disclosure.

FIG. 1 is a diagram illustrating an example of an apparatus 100 forgenerating a test bench for verifying a processor decoder. Referring toFIG. 1, the apparatus 100 includes a receiver 110, a parser 120, and agenerator 130.

The receiver 110 may receive an architecture description includingdecoder information of a processor. The parser 120 may parse a languageof the received architecture description into information to verify adecoder of the processor.

The decoder of the processor decodes an encoded instruction. The decoderseparates the instruction including operation code (op-code)information, source information, and destination information from thereceived encoded information. Therefore, the encoded information refersto the decoded information that was received.

The generator 130 may generate a test bench for verifying the decoder ofthe processor by using the parsed information.

FIG. 2 is a diagram illustrating an example of an apparatus 200 forgenerating a test bench for verifying a processor decoder. Referring toFIG. 2, the apparatus 200 includes a receiver 210, a parser 220, agenerator 230, and a comparator 240.

The receiver 210 may receive an architecture description includingdecoder information of a processor.

The parser 220 may parse a language of the received architecturedescription as information to verify a decoder of the processor.

The received architecture description may include at least one ofencoding scheme information, encoding bitmap information, or op-codeinformation.

The encoding scheme information may include information about how aninstruction is constituted.

The encoding bitmap information may include information about how manybits are allocated to each part of the instruction.

Structures of components of the encoding scheme information and theencoding bitmap information may be distinguished for parsing thelanguage of the received architecture description to generate a testbench.

The generator 230 may generate the test bench using the parsedinformation. The test bench may include a test vector or a referencemodel of the decoder of the processor.

The comparator 240 may input the test vector of the apparatus 200 intothe reference model and a design under test (DUT) processor decoder andcompare the input results. The DUT processor decoder may include a verylong instruction word (VLIW) processor decoder and a processor decoderhaving a coarse grained reconfigurable architecture (CGRA) structure.

FIG. 3 is a diagram illustrating an example of a test bench 340 forverifying a processor decoder. The test bench 340 may include a testvector 300 and a reference model 310 that are generated by the generator230 of FIG. 2. The reference model 310 may correspond to the referencemodel 310 of a processor decoder to be verified. The test vector 300 isinput into the reference model 310 and a DUT processor decoder 320.

The DUT processor decoder 320 may be selected by a user. An architecturedescription may be an architecture description of a DUT processordecoder. The architecture description may vary according to processors.

The comparator 330 compares a result of the test vector 300 passingthrough the reference model 310 with a result of the test vector 300passing through the DUT processor decoder 320 to determine a pass and/orfail of a test.

FIG. 4 is a diagram illustrating an example of information of anarchitecture description.

Referring to FIG. 4, the information of the architecture description mayinclude one of encoding scheme information, encoding bitmap information,or op-code information. The encoding scheme information may includegroup code information.

The information of the architecture description may be expressed in alanguage, such as, for example, C language or verilog language. Theinformation of the architecture description is not limited to a type ofa particular programming language. Other programming languages fordescribing the architecture are considered to be well within the scopeof the present disclosure.

The encoding bitmap information may include information about how manybits are allocated to destination information.

The group code information may correspond to bits from a first bit to asixth bit from the left of 32 bits of an instruction.

If “<src0 name=“reg_pos0” type=“reg”/>” is interpreted using the Clanguage, a name of “source 0” may be expressed as “reg_pos0” on adecoder.

If “<src1 name=“regpos2” type=“reg”/>” is interpreted using the Clanguage, a name of source 1 may be expressed as “reg_pos2” on thedecoder.

If “<dest0 name=“reg_pos1”/>” is interpreted using the C language, aname of destination 0 may be expressed as “reg_pos1” on the decoder.

If “<stop name=“stop_1”/>” is interpreted using the C language, a nameof a stop instruction may be expressed as “stop1” on the decoder.

FIG. 5 is a diagram illustrating an example of a reference model of aprocessor decoder. Referring to FIG. 5, the reference model of theprocessor decoder indicates which part of an instruction is an op-codeand which part is a register, through information of an architecturedescription.

In a switch sentence realized in a C language, an operation is performedon an instruction and a part “fc000000” with code “&” to insert a groupcode as an input.

Since the part “fc000000” is hexadecimal numbers, the part “fc000000”may be expressed in binary numbers as “1111 1100 0000 0000 0000 00000000 0000.” Therefore, first through sixth bits from the left of theinstruction may be extracted as inputs.

The first through sixth bits from the left is a part that indicates agroup code as shown in FIG. 4.

If 32 bits of the instruction is formed of “0000 0011 0100 0000 00000000 0000 0000”, first through sixth bits from the left are all 0, andthus a group code may be 0. Therefore, if the group code is 0, case 0 isexecuted. If the group code is 1, case 1 is executed.

As seen from “opcode=d1_instr & 0x03f80000;” an operation may beperformed on the instruction of 32 bits and “03f80000” with the code “&”to express an op-code.

“03f80000” is expressed as 16 numbers and may be expressed as binarynumbers “0000 0011 1111 1000 0000 0000 0000 0000”. In other words,seventh through 13th instructions from the left may indicate op-codes.

As seen from “reg_pos0=c11_instr & 0x0007e000;” an operation may beperformed on the instruction of 32 bits and “0007e000” with the code “&”to express “reg_pos0” as a register address indicating a source.

“0007e000” is expressed as hexadecimal numbers and may be expressed asbinary numbers “0000 0000 0000 0111 1110 0000 0000 0000”. In otherwords, six bits of 14th through 19th instructions indicate “reg_pos0” asa register address indicating a source.

As seen from “reg_pos1=d1_instr & 0x00001f80;” an operation may beperformed on an instruction of 32 bits and “00001f80” with the code “&”to express “reg_pos1” as a register address having information of adestination.

“00001f80” is expressed as hexadecimal numbers and may be expressed asbinary numbers “0000 0000 0000 0000 0001 1111 1000 0000”. In otherwords, six bits of 20th through 25th instructions from the left mayindicate “reg_pos1” as a register address having information of adestination.

As seen from “reg_pos2=d1_instr & 0x0000007e;” an operation may beperformed on an instruction of 32 bits and “0000007e” with the code “&”to express “reg_pos2” as a register address indicating a source.

“0000007e” is hexadecimal numbers and may be expressed as binary numbers“0000 0000 0000 0000 0000 0000 0111 1110”. In other words, six bits of26th through 31th instructions may indicate “reg_pos2” as a registeraddress indicating a source.

As seen from “stop_1=d1_instr & 0x00000001;” an operation may beperformed on an instruction of 32 bits and “00000001” with the code “&”to express “stop_1” as a register address.

“00000001” is expressed as hexadecimal numbers and may be expressed asbinary numbers “0000 0000 0000 0000 0000 0000 0000 0001”. In otherwords, one bit of a 32th instruction may indicate “stop_1” indicatinginformation of a stop instruction.

As described above, all inputs for a decoder, including an op-codelength, a source length, and a destination length of a processor, may beacquired.

FIG. 6 is a diagram illustrating an example of a method of generating atest bench for verifying a processor decoder. The operations in FIG. 7may be performed in the sequence and manner as shown, although the orderof some operations may be changed or some of the operations omittedwithout departing from the spirit and scope of the illustrative examplesdescribed. Many of the operations shown in FIG. 7 may be performed inparallel or concurrently. Referring to FIG. 6, the method includesoperations that are processed by the apparatus 100 of FIG. 1 in timeseries. Therefore, the descriptions of the apparatus 100 of FIG. 1 isincluded in the description of the method of FIG. 6, and will not berepeated here.

In operation 600, an architecture description including processordecoder information is received. Information about instruction encodingof a processor is included in the architecture description. Theinformation about the instruction encoding of the processor is forcompiling performed by a compiler. Since encoding information is thesame as decoding information, the architecture description may includeinformation about the processor decoder.

In operation 610, a language of the received architecture description isparsed into information for verifying the processor decoder. Thelanguage of the architecture description may not be used straight awayto generate a test bench for verifying the processor decoder. Togenerate the test bench for verifying the processor decoder, thelanguage of the architecture description may be parsed so that theinformation for verifying the processor decoder is appropriate forgenerating the test bench.

In operation 620, the test bench for verifying the processor decoder maybe generated by using the parsed information. The test bench may includea test vector and a reference model of a DUT processor decoder. The testvector may be changed into another input and then inserted by a user andmay include all inputs that may be inserted into the decoder.

FIG. 7 is a diagram illustrating an example of a method of generating atest bench for verifying a processor decoder. The operations in FIG. 7may be performed in the sequence and manner as shown, although the orderof some operations may be changed or some of the operations omittedwithout departing from the spirit and scope of the illustrative examplesdescribed. Many of the operations shown in FIG. 7 may be performed inparallel or concurrently.

Referring to FIG. 7, the method includes operations that are performedby the apparatus 200 of FIG. 2 in time series. Therefore, thedescriptions of the apparatus 200 of FIG. 2 is included in thedescription of the method of FIG. 7, and will not be repeated here.

Operations 700, 710, and 720 are similar to operations 600, 610, and 620of FIG. 6, and is incorporated herein by reference. Thus, the abovedescription may not be repeated here.

In operation 730, results of inputting a test vector into a referencemodel and a DUT processor decoder may be compared.

The DUT processor decoder and the reference model receive the testvector to transmit outputs of the test vector. The outputs of thereference model and the DUT processor decoder may be compared to verifywhether a processor decoder has failed or not. If the results are thesame, the processor decoder may be passed. If the results are different,the processor decoder is deemed to have failed.

According to the one or more general aspect, a DUT processor decoder maybe variously changed, but test benches may not need to be written forprocessor decoders through an input from a user. A test bench may beautomatically written through a given architecture description to reducea time for verifying all processor decoders. Information for generatingthe test bench may use the architecture description used by a compiler,and thus a time taken for the input from the user may be reduced.

The processes, functions, and methods described above can be written asa computer program, a piece of code, an instruction, or some combinationthereof, for independently or collectively instructing or configuringthe processing device to operate as desired. Software and data may beembodied permanently or temporarily in any type of machine, component,physical or virtual equipment, computer storage medium or device that iscapable of providing instructions or data to or being interpreted by theprocessing device. The software also may be distributed over networkcoupled computer systems so that the software is stored and executed ina distributed fashion. In particular, the software and data may bestored by one or more non-transitory computer readable recordingmediums. The non-transitory computer readable recording medium mayinclude any data storage device that can store data that can bethereafter read by a computer system or processing device. Examples ofthe non-transitory computer readable recording medium include read-onlymemory (ROM), random-access memory (RAM), Compact Disc Read-only Memory(CD-ROMs), magnetic tapes, USBs, floppy disks, hard disks, opticalrecording media (e.g., CD-ROMs, or DVDs), and PC interfaces (e.g., PCI,PCI-express, WiFi, etc.). In addition, functional programs, codes, andcode segments for accomplishing the example disclosed herein can beconstrued by programmers skilled in the art based on the flow diagramsand block diagrams of the figures and their corresponding descriptionsas provided herein.

The apparatuses and units described herein may be implemented usinghardware components. The hardware components may include, for example,controllers, sensors, processors, generators, drivers, and otherequivalent electronic components. The hardware components may beimplemented using one or more general-purpose or special purposecomputers, such as, for example, a processor, a controller and anarithmetic logic unit, a digital signal processor, a microcomputer, afield programmable array, a programmable logic unit, a microprocessor orany other device capable of responding to and executing instructions ina defined manner. The hardware components may run an operating system(OS) and one or more software applications that run on the OS. Thehardware components also may access, store, manipulate, process, andcreate data in response to execution of the software. For purpose ofsimplicity, the description of a processing device is used as singular;however, one skilled in the art will appreciated that a processingdevice may include multiple processing elements and multiple types ofprocessing elements. For example, a hardware component may includemultiple processors or a processor and a controller. In addition,different processing configurations are possible, such a parallelprocessors.

While this disclosure includes specific examples, it will be apparent toone of ordinary skill in the art that various changes in form anddetails may be made in these examples without departing from the spiritand scope of the claims and their equivalents. The examples describedherein are to be considered in a descriptive sense only, and not forpurposes of limitation. Descriptions of features or aspects in eachexample are to be considered as being applicable to similar features oraspects in other examples. Suitable results may be achieved if thedescribed techniques are performed in a different order, and/or ifcomponents in a described system, architecture, device, or circuit arecombined in a different manner and/or replaced or supplemented by othercomponents or their equivalents. Therefore, the scope of the disclosureis defined not by the detailed description, but by the claims and theirequivalents, and all variations within the scope of the claims and theirequivalents are to be construed as being included in the disclosure.

What is claimed is:
 1. A method of generating a test bench to verify aprocessor decoder, the method comprising: receiving an architecturedescription comprising processor decoder information; parsing thereceived architecture description into parsed information for verifyingthe processor decoder; generating the test bench automatically to verifythe processor decoder based on the parsed information, wherein the testbench includes a test vector and a reference model of the processordecoder; comparing respective results of inputting the test vector intothe reference model and a design under test (DUT) processor decoder; andverifying the processor decoder based on the respective results.
 2. Themethod of claim 1, wherein the parsing of the received architecturedescription comprises acquiring operation code (op-code) information,source information, and destination information from the receivedarchitecture description.
 3. The method of claim 2, wherein the op-codeinformation comprises an operation code specification, the sourceinformation comprises a source length, and the destination informationcomprises a destination length.
 4. The method of claim 1, wherein thearchitecture description comprises at least one of encoding schemeinformation, encoding bitmap information, and operation code (op-code)information, and the encoding scheme information comprises group codeinformation.
 5. The method of claim 1, wherein the processor decoder isone of a very long instruction word (VLIW) processor decoder or aprocessor decoder having a coarse grained reconfigurable architecture(CGRA) structure.
 6. An apparatus for generating a test bench to verifya processor decoder, the apparatus comprising: a receiver configured toreceive an architecture description comprising processor decoderinformation; a parser configured to parse the received architecturedescription into parsed information for verifying the processor decoder;a generator configured to automatically generate the test bench toverify the processor decoder based on the parsed information, whereinthe test bench includes a test vector and a reference model of theprocessor decoder; and a comparator configured to compare respectiveresults of inputting the test vector into the reference model and adesign under test (DUT) processor decoder, and verify the processordecoder based on the respective results.
 7. The apparatus of claim 6,wherein the parser is further configured to acquire operation code(op-code) information, source information, and destination informationfrom the received architecture description.
 8. The apparatus of claim 7,wherein the op-code information comprises an operation codespecification, the source information comprises a source length, and thedestination information comprises a destination length.
 9. The apparatusof claim 6, wherein the architecture description comprises at least oneof encoding scheme information, encoding bitmap information, andoperation code (op-code) information, and the encoding schemeinformation comprises group code information.
 10. The apparatus of claim6, wherein the processor decoder is one of a VLIW processor decoder or aprocessor decoder having a CGRA structure.
 11. A non-transitorycomputer-readable medium storing a computer program which when executedby a computer processor configures the computer processor to: receive anarchitecture description comprising information associated with aprocessor decoder; parse the architecture description into parsedinformation for verifying the processor decoder; automatically generatea test bench to verify the processor decoder based on the parsedinformation, wherein the test bench includes a test vector and areference model of the processor decoder; compare respective results ofinputting the test vector into the reference model and a design undertest (DUT) processor decoder; and verify the processor decoder based onthe respective results.
 12. The non-transitory computer-readable mediumof claim 11, wherein the computer program when executed configures thecomputer processor to acquire operation code (op-code) information,source information, and destination information from the receivedarchitecture description.
 13. The non-transitory computer-readablemedium of claim 12, wherein the op-code information comprises anoperation code specification, the source information comprises a sourcelength, and the destination information comprises a destination length.14. The non-transitory computer-readable medium of claim 11, wherein thearchitecture description comprises at least one of encoding schemeinformation, encoding bitmap information, and operation code (op-code)information, and the encoding scheme information comprises group codeinformation.
 15. The non-transitory computer-readable medium of claim11, wherein the processor decoder is one of a very long instruction word(VLIW) processor decoder or a processor decoder having a coarse grainedreconfigurable architecture (CGRA) structure.